Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

schedule regular build and test #1373

Merged
merged 4 commits into from
Apr 29, 2024
Merged

schedule regular build and test #1373

merged 4 commits into from
Apr 29, 2024

Conversation

tigercosmos
Copy link
Collaborator

schedule a build every day. In case the CI is broken unexpectedly.

@tigercosmos tigercosmos requested a review from seladb as a code owner April 24, 2024 14:14
@@ -4,6 +4,8 @@ on:
branches: ["master", "dev"]
pull_request:
branches: ["dev"]
schedule:
- cron: '0 0 * * *'
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

run build at 00:00 every day.

@seladb
Copy link
Owner

seladb commented Apr 25, 2024

@tigercosmos I'm not sure we need a daily build. If CI breaks we usually know it from existing PRs...

@tigercosmos
Copy link
Collaborator Author

@tigercosmos I'm not sure we need a daily build. If CI breaks we usually know it from existing PRs...

@seladb That's the issue. We need to have a PR to know if the CI is broken, but we don't have PR every day. When the CI is broken, the PR usually needs to wait for the CI fixed, which is inefficient.
Instead, we should have at least one build every day, to ensure that whenever a PR is opened, the CI can always function.

@seladb
Copy link
Owner

seladb commented Apr 25, 2024

@tigercosmos I'm not sure we need a daily build. If CI breaks we usually know it from existing PRs...

@seladb That's the issue. We need to have a PR to know if the CI is broken, but we don't have PR every day. When the CI is broken, the PR usually needs to wait for the CI fixed, which is inefficient. Instead, we should have at least one build every day, to ensure that whenever a PR is opened, the CI can always function.

I'm not sure it's really needed because if there's no PR then there's no need to fix CI 🙂
I'm curious what @clementperon and @egecetin think about it

@tigercosmos
Copy link
Collaborator Author

@seladb For certain issues, such as the recent one with CMake, having regularly scheduled builds enables us to identify such issues sooner.

@egecetin
Copy link
Collaborator

@seladb @tigercosmos It is good to know if something is broken but fast response can also make some things more complicated. Think about the latest breaking change in CMake. If we saw this on day one, we might think we should change something to fix instead of waiting CMake to fix their problem 🤔. Even if we know something is broken with scheduled workflows, we should still wait some time before changing something in library, I think.

Currently PcapPlusPlus is active enough to check workflows because every week there are more than one PRs. But I have a question, why only build_and_test runs? We should run probably all of them (including packaging) or maybe just trig rarely running workflows (like packaging) with scheduling. Because actually we won't notice for months if there is a problem with packaging.

My biggest concern is workflow time. Currently we have lots of runners (and we should have them because pcpp is multi-platform) and they consume a bit of time to run (Looks like 3min - 15min) and we rely on GitHub actions, so we don't have a custom queue or priority queue etc. Because concurrency limits in GitHub it might consume more time to run workflows when there is ongoing PRs. So instead of every day maybe just trigger every week? So even if there is no PR for a while, we can check the situation.

@tigercosmos
Copy link
Collaborator Author

tigercosmos commented Apr 25, 2024

@egecetin I only added build_and_test because they are more likely to be broken. I don't think fuzz testing or documents will break easily. Of course, if we don't care about the overall running time of the full CIs, we can have all the CIs run.

Regarding your concern about the execution time, I don't think it is an issue, we only occupy the CI 10 minutes a day, and we don't have many PRs that need to run CI in a day. But I am also fine to have one run per week.

@seladb
Copy link
Owner

seladb commented Apr 26, 2024

Maybe we should just run the packaging CI once a week or so? 🤔

@tigercosmos
Copy link
Collaborator Author

@seladb @egecetin I make all CI run once a week.

@egecetin
Copy link
Collaborator

egecetin commented Apr 27, 2024

I'm ok for both run all CI or just packaging only. It is up to you 👍.

@@ -2,7 +2,7 @@ name: Auto Update

on:
schedule:
- cron: '10 10 15 * *'
- cron: '0 0 * * 0' # Run every Sunday at midnight
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't want to run auto_update on a weekly basis, once a month is enough...

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure, let me change it

@tigercosmos
Copy link
Collaborator Author

@seladb should be ready for review.

@tigercosmos tigercosmos merged commit a8b538f into seladb:dev Apr 29, 2024
66 of 67 checks passed
@tigercosmos tigercosmos deleted the ci_0424 branch May 15, 2024 17:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants